pldm: Move the IPC server onto the shared service seam - #499

The FD side of the IPC channel. dispatch() decodes the orchestrator's
request header, matches on PldmOp, calls the corresponding FdHandler
trait method, and encodes the response. FdHandler has one method per
opcode so the implementation never touches wire bytes.

LoopbackTransport implements pldm_ipc_api::Transport by calling
dispatch directly in-process. Dispatch runs inside start(), so the
response is ready on the first poll(); the split-phase shape is kept
so client code written against a real channel runs unchanged here.
The loopback tests show a multi-step sequence (accept offer, then
query status shows ReadyXfer), proving the wire format, dispatch, and
status encoding work together, plus the state rules: start while
pending, poll with nothing in flight, cancel, and a short response
buffer.

Same pattern as services/i2c/server: dispatch generic over a trait,
loopback transport in the server crate, host-buildable with no kernel
dependencies.

Assisted-by: Claude Code

Deletes the two local copies: ipc-api's Transport trait, which was
character-identical to util_service::AsyncTransport, and ipc-server's
LoopbackTransport, which was util_service::Loopback around dispatch.
The api crate is now wire format only, and the transport that carries
its frames is the one every IPC service shares.

FdServer is the Dispatch impl. The newtype exists because Dispatch is a
foreign trait and cannot be implemented for every F: FdHandler directly.
dispatch() returns Result: a response buffer too small for even an error
frame is the one case with nothing to send back, where it used to return
a bare 0.

The request length check is now per opcode. expected_request_len(op)
returns the exact frame size for each operation, so a frame with
trailing slack is rejected before dispatch. The match has no catch-all,
so adding an opcode without choosing its length fails to compile.

Assisted-by: Claude